Description

• Adds the I2C_ADXL343 example to the MAX32690.
• Reformat I2C transactions in ADXL343 drivers to account for repeated start condition (shortening for RSC) protocol used with ADXL343. (More info below).
• Fix errata rev 2, 16 - Enabling I2C alternate functions disables the functionality of some pins, specifically for I2C2 instance.
• Use the correct I2C (MSTCTRL.stop) register when the CONTROLLER (prev. MASTER) sets the STOP condition. I2C_INTFL0.stop is for when the device is in TARGET (prev. SLAVE) mode and detects a STOP condition.

When testing on the ME18, the MasterTransaction function doesn't support repeated start conditions in the protocol that ADXL343 supports for all-in-one transaction requests due to how the request struct and the driver's reads logic are set up for a single transaction call (read -> check comm error -> restart read if still expecting more messages -> repeat back to step 1 (read) until all reads finish).

For reference, this is the READ RSC protocol for the ADXL343 (common for other ICs with accessible registers as well).

Back to the read logic in the MasterTransaction function, the last step before the repeat (restart read if still expecting more messages) causes a double readback and hanging transaction failures when attempting to run the READ RSC transaction mentioned above. Removing the last step is a temporary workaround to prevent double readbacks and support RSC-type transactions, but it breaks normal/non-RSC I2C transactions.

Adding a solution to support both normal and RSC transactions will be too invasive and require more time to verify. Because this PR has been blocking this upcoming release, investigating further into this matter will have to wait until after the release. For now, I left the I2C drivers (specifically MasterTransaction) as is, similar to our previous releases, and any RSC-type transactions will have to be done (at least for the ADXL343) using two I2C_MasterTransaction calls: the first transaction will be everything that happens BEFORE the second START condition (which is writing which register to read from), and the second transaction will be everything that happens AFTER the second START condition (which is reading the contents of the written register).

Checklist Before Requesting Review

• PR Title follows correct guidelines.
• Description of changes and all other relevant information.
• (Optional) Link any related GitHub issues using a keyword
• (Optional) Provide info on any relevant functional testing/validation. For API changes or significant features, this is not optional.